Support dots in target names when writing to an override block - #6148

…hange (databricks#6138)

## Problem

A resource's sequence field (e.g. job `tasks`) can be written in two
physical YAML regions: the top-level `resources.*` block and a
`targets.` override, either possibly in its own included file. Loading
merges them into one list and sorts keyed lists by key.

Config-sync resolves a change against that **merged** list, then writes
it using the merged position, which causes out-of-bound indexing issues
or issues with config corruption

## Solution

`bundle/configsync/blockindex.go` maps every `dyn.Location` back to the
block that owns it (not only a file), so a destination is *looked up*,
and `resolveSelectors` rewrites merged positions into block-local ones.

Blocks are recovered by re-parsing the contributing files, because
selecting a target destroys the distinction (it folds overrides into
`resources` and drops `targets`). Re-parsing, rather than reloading via
the mutator pipeline, avoids running the bundle's `preinit` script twice
per sync.

Guiding rule: **correct write > no write > wrong write.** Anything
ambiguous is left for a later run.

How a destination is picked:

- element defined in one block → that block;
- element defined in several → the **field** decides, since each field
has its own location, so two fields of one task can go to two different
blocks;
- field itself defined in several → the definition that **won the
merge**: the target override, or between two files in the same scope the
one loaded later. Writing the shadowed copy would leave the effective
value unchanged, so the sync would re-detect the same change on every
run;
- **removing** anything defined in several blocks → one deletion per
definition, since it only disappears once every copy is gone. This
applies to a *field* as well as an element: deleting only the winning
copy lets the shadowed one take effect, so the next deploy restores the
value the user just removed;
- **renaming** → a replace of just the key field in every defining
block, so other fields stay in their own scope. A key change arrives as
an unlinked remove plus add; the two are paired by identity;
- brand-new element or field → the block declaring the resource. A field
a mutator inserted (e.g. `OverrideCompute` setting
`existing_cluster_id`) counts as new: the value is present but carries
no location, so no block declares it;
- otherwise → left unapplied rather than written to a guess.

Also worth knowing: index bookkeeping is per block, so a removal in one
block cannot shift positions in another; rename pairing refuses
ambiguous matches in both directions; and a target override may
legitimately span several files, so a block is identified by (scope,
file)

## Tests

New acceptance tests, a lot of test cases to cover everything that this
refactoring touched, but all are local as we only need to cover config
resolution

## Follow-ups

Stacked on this branch, each independently reviewable:

- **databricks#6146** — report changes that were detected but not written back.
Today every drop path is a `log.Debugf` while the command prints the
full changeset and exits 0, so a dropped edit is indistinguishable from
an applied one.
- **databricks#6148** — support a dot in a target name (`targets: {dev.eu: ...}`).
Pre-existing on `main`, but it fails the whole command rather than
skipping one change.

Rebase onto `main` once this merges.